fix(dev): fix frontend dev server startup race#5776
Conversation
WalkthroughThe development startup path now uses a context-aware helper to probe the frontend server with timed retries and HTTP timeouts. Errors are returned from ChangesFrontend readiness
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant preRun
participant waitForFrontendDevServer
participant httpClient
participant FrontendDevServer
participant Context
preRun->>waitForFrontendDevServer: readiness URL and context
waitForFrontendDevServer->>httpClient: execute cloned GET request
httpClient->>FrontendDevServer: probe frontend server
FrontendDevServer-->>httpClient: response or connection error
waitForFrontendDevServer->>Context: check cancellation between attempts
waitForFrontendDevServer-->>preRun: success or returned error
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
This was my constant struggle while I develop Windows App. I don't know, maybe because of Windows Defender or something else, but on Windows frontend part start kind of long and I was contantly getting this race: This PR fixes my issues completely. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@v3/pkg/application/application_dev.go`:
- Around line 25-26: Update the frontend readiness loop around client.Get in
application startup to enforce a request timeout, using an http.Client with a
finite Timeout or a context deadline for each request. Preserve the existing
retry behavior while ensuring an unresponsive frontend cannot block startup
indefinitely.
- Line 25: Update the retry documentation associated with the loop in
application startup to state that the server is retried a maximum of 30 times,
matching the loop’s 30 iterations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 54c051b6-72c9-4c79-b358-c53a6af957ca
📒 Files selected for processing (2)
v3/internal/commands/dev.gov3/pkg/application/application_dev.go
fc9f35a to
dc1e1d3
Compare
…gic and test coverage
dc1e1d3 to
f84439e
Compare
|
@leaanthony could you review please? This is SO persistent on Windows, I am tired to restart |
Description
Fixes a race in
wails3 devwhere the native application may exit before the frontend dev server becomes ready.The watcher starts the frontend task in the background and immediately launches the application. Previously, the application stopped waiting after 10 attempts at 500 ms intervals. Frontends that took slightly longer than five seconds to start caused a fatal error.
Fixes # (issue)
Type of change
Please select the option that is relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration using
wails doctor.If you checked Linux, please specify the distro and version.
Test Configuration
Please paste the output of
wails doctor. If you are unable to run this command, please describe your environment in as much detail as possible.Checklist:
website/src/pages/changelog.mdxwith details of this PR (v3 changelog entries are added automatically)Summary by CodeRabbit
Bug Fixes
Tests